With the advent of more robust wireless communications systems, compatible handheld communication devices are becoming more prevalent, as well as advanced. In a broader sense, these devices are referred to as handheld electronic devices, which include devices without communication functions. Where in the past such handheld communication devices typically accommodated either voice (cell phones) or text transmission (pagers and PDAs), today's consumer often demands a combination device capable of performing both types of transmissions, including sending and receiving e-mail. The suppliers of such mobile communication devices and underlying service providers are anxious to meet these demands, but the combination of voice and textual messaging, as well as other functionalities such as those found in PDAs, have caused designers to have to improve the means by which information is input into the devices by the operator, as well as provide better facilitation for the operator/user to navigate within the menus and icon presentations necessary for efficient operator interface with these more complicated devices.
For many reasons, screen icons are often utilized in such handheld communication devices as a way to allow operators to make feature and/or function selections. Among other reasons, operators are accustomed to such icon representations for function selection. A prime example is the personal computer “desktop” presented by Microsoft's Windows® operating system. Because of the penetration of such programs into the user markets, most electronics users are familiar with what has basically become a convention of icon-based functionality selections. Even with many icons presented on a personal computer's “desktop”, however, user navigation and selection among the different icons is easily accomplished utilizing a conventional mouse and employing the point-and-click methodology. The absence of such a mouse from these handheld wireless communication devices, however, has caused a different protocol to develop for icon navigation and selection.
As depicted in FIG. 1, the icons (squares 1, 2, 3 and 4) displayed on the screen of the device are typically presented in an array of uniform rows and columns. As an example, a home screen might present icons for telephone, e-mail, calendar and contact functions. Because there is no “mouse,” other auxiliary navigational tools are typically provided for operator manipulation in affecting movement between the different icons on a handheld device. Such navigational tools have included rotatable thumb wheels, joysticks, touchpads, four-way cursors and the like. In the present description, a trackball is also disclosed as a navigational tool for enabling an operator to move about displayed icons. The navigational tool is a type of auxiliary input device and hereinbelow the navigational tool maybe described more generally as an auxiliary user input.
In the trackball instance, current technology calls for the utilization of paired sensors located about the trackball for sensing rotational motion of the trackball which is representative of the desired direction the user would like the cursor to move on the screen, including a highlighting cursor that moves discretely amongst screen-displayed icons. The trackball itself is capable of free rotation within its receiving socket which gives the operator an impression that he or she can direct cursor motion on the screen (be it an icon highlighting cursor or a more traditional cursor such as a floating arrowhead) in any direction desired within the area of the display screen.
Not only is the trackball enabled for directing cursor movement on the display screen, but the ball itself is configured to be depressible so that when actuated (depressed), a selection is made just as if an equivalent button had been depressed. In this manner, the trackball is provided at least with dual functionality (navigation and selection). By providing this dual functionality in the trackball, inclusion of such an equivalent button is avoided thereby preserving prime “real estate” on the device for other uses. A problem, however, exists between this duality in functionality of the trackball and the manner in which an operator typically engages the trackball for depressed actuation. Very rarely will the operator's finger/thumb come directly down upon the trackball when press-engaging. Instead, initial engagement is nearly always a “glancing” engagement which means that the operator's digit is not only coming down on the trackball, but is also traveling thereacross. This sideways engagement induces rolling in the trackball that in some instances can cause the cursor to move from the intended location before depressed actuation (highlighted information selection) is accomplished. If this results, a wrong selection is highly likely. Therefore one aspect of the present disclosure details how to prevent such inadvertent cursor movement when in fact it is depressed actuation and selection that the operator intends.
Another constraint of the paired sensor configuration described above is that even though the trackball enjoys free rotation, its rotational movement must be resolved into X and Y components via the motion sensors. Therefore, movement between icons has been limited to up, down and sideways motion. More specifically, diagonal movement between icons has not been previously facilitated. As an example, and returning again to FIG. 1, if the operator desired to move from icon “1” to icon “4”, execution would have to be either over to icon “2” and down to icon “4” or down to icon “3” and over to icon “4”. A similar situation exists when navigating across such applications as spreadsheets composed of a grid of cells where diagonal cell-to-cell movement can be desirable, but until now, undesirable zigzag cursor motion has been required.
Since these limitations are counterintuitive given the fact the trackball enjoys free rotation but the operator cannot move diagonally from icon to icon in a single step, frustration and product dissatisfaction are likely. Therefore, a primary aspect of the presently disclosed solution is the enablement of such direct diagonal movement between icons, even when the signals developed using the navigational tool are X and Y direction limited.
It should be appreciated that the examples of icon and spreadsheet navigation present a special problem typically not encountered when navigating across continuous screen fields such as, for example, when cursor-traversing a map that is presented on the screen. In the instance of at least trackball navigation, the individual X and Y signal components will normally be fine (small) enough to even be executed on a pixel-by-pixel basis. As a result, in most cases, the operator will not be able to visually detect that he or she is getting X-Y stepped movement of the cursor; to the eye, the steps are so small (pixel-by-pixel) that the cursor appears to be moving on a diagonal or smooth curve when accordingly directed. It should be appreciated, however, that there are certain configurations in which the X-Y limited movement is not sufficiently fine and the operator perceives an undesirable zig-zag motion of the cursor. Therefore the presently presented solutions focus on enabling an operator to diagonally navigate a cursor on a screen of a handheld electronic device by “blending” X and Y direction signals into diagonal signals for affecting diagonal cursor movement, and particularly in environments such as icon fields and spreadsheet matrices, and especially without experiencing undue delay or lag between the input of the instruction and the cursor's actual movement.
In another aspect, because these handheld electronic devices are getting substantially smaller and users are demanding greater and constant access, the devices are often carried in the user's pocket. Furthermore, since the trackball is exposed and rotates freely at the surface of the device, it is susceptible to unintentional and usually undesirable rotation. As an example, this can occur when the user places the handheld electronic device in his or her pocket and the rubbing of the fabric against the trackball causes unintentional rolling of the trackball. The undesirable nature of this occurrence is at least partly attributable to the fact that actuation of a device's navigation tool traditionally restores power to the screen (after having entered a sleep mode) because it is usually interpreted as an indication that the user wants to use the device in some capacity. Therefore, if the trackball is frequently unintentionally actuated, the screen will be lit unnecessarily, wasting battery power.
As described above, in the instance of a trackball being used as the navigation tool, sensors are required to detect motion of the trackball. Therefore, in order to be able to detect rollerball motion indicative of desired use, the sensors must always be powered-on which consumes energy and reduces the energy savings experienced because the screen has been put into sleep mode.
The present disclosure is directed toward minimizing or eliminating the deficiencies outlined above and which would otherwise prevail except for the mitigating solutions described and disclosed herein.